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Description 

SYSTEMS AND METHODS FOR 
PROVIDING A RF TRANSACTION DEVICE 
OPERABLE TO STORE MULTIPLE 
DISTINCT ACCOUNTS 

Cross Reference to Related Applications 

[0001] This application is a continuation-in-part of and claims 
priority to U.S. Patent Application No. 10/608,742, enti- 
tled "METHOD AND APPARATUS FOR ENROLLING WITH 
MULTIPLE TRANSACTION ENVIRONMENTS," filed June 27, 
2003, and U.S. Patent Application No. 10/435,420, enti- 
tled "SYSTEM AND METHOD FOR MANAGING ACCOUNT 
INFORMATION LIFE CYCLES," filed May 9, 2003, both of 

which are hereby incorporated by reference. 
Field of Invention 

[0002] The present invention generally relates to payment sys- 
tems, and more particularly, to systems and methods for 
facilitating the adding of multiple data sets on various 



card and "non-card" transaction enabling devices, includ- 
ing financial instruments. 
Background of Invention 



[0003] Some financial transaction devices, such as credit cards 

and loyalty program cards, are capable of accessing infor- 
mation related to multiple accounts. For example, a credit 
card may be able to access membership data associated 
with both a credit card account and a wholesale purchase 
club account. These financial transaction devices may 
generally include one or more applications for selecting 
and then securely utilizing a sub-set of specified account 
information. For example, the selecta-card system dis- 
closed in U.S. Patent Application No. 6,685,088 issued 
February 3, 2004 to Royer, et al., discloses a method 
which provides a means to use a single transaction card to 
facilitate transactions with a variety of transaction account 
devices. Accordingly, multiple accounts are associated 
with a selecta-card by pre-selected account identification 
numbers. To facilitate a transaction with a selecta-card, a 
cardholder enrolls in a selecta-card account system, pro- 
viding account identification numbers corresponding to 
desired cardholder-identified transaction accounts. When 
making a purchase, the cardholder swipes the selecta- 



card through a remote terminal such as a POS device, 
wherein the selecta-card number is read and communi- 
cated to a selecta-card provider. To choose which trans- 
action account to use for the purchase, the cardholder in- 
puts an account identification number corresponding to a 
pre-defined transaction account, the selecta-card 
provider retrieves the corresponding transaction account 
and processes cardholder transaction request accordingly. 

[0004] However, the systems associated with these cards typically 
delegate the loading of these applications and manage- 
ment of the related data sets to third parties on behalf of 
both the issuer of the device and "application tenants" re- 
siding on the issuer's financial transaction devices. Man- 
aging data associated with a credit card via the issuer/ 
third party may involve time consuming steps such as re- 
questing permission to manage data, conforming to data 
standard formats, and implementing changes. Thus, tra- 
ditional solutions for managing multiple application ten- 
ants are disadvantageous in that the traditional solutions 
leave a disproportional burden on the issuer and/or the 
delegated third party in terms of managing accounts on a 
financial transaction device. 

[0005] Another disadvantage is that, in general, the financial 



transaction devices, which are capable of accessing infor- 
mation related to multiple accounts, are typically designed 
to access only those multiple accounts managed by the 
same issuer. That is, in some cases, the issuer may em- 
ploy access prevention protocol to prevent access to the 
information from those not authorized, and to permit ac- 
cess to those persons who have the two accounts issued 
by the same user. For example, the same issuer provides 
both the credit card and the wholesale purchase club ac- 
count to the user. As such, the issuer providing both ac- 
counts generally establishes its own application tenant 
storage format and management protocol related to the 
accounts. The established format and protocol is ordinar- 
ily different from any format or protocol used by other 
unrelated issuers, which provides the issuer increased 
control over access to the account data. Because of the 
differing unique protocols/formats amongst issuers, mul- 
tiple issuers typically provide a transaction device corre- 
sponding to an account offered by the issuer, where the 
data for accessing the account is stored in that issuer's 
protocol/format. Thus, a user wishing to access multiple 
accounts managed by different issuers, must ordinarily 
carry at least one transaction device per issuer. Carrying 



multiple transaction devices can be inconvenient in that 
the devices may be more easily misplaced, lost or stolen 
preventing the user from accessing the account. 

[0006] still another disadvantage is that a user having multiple 
transaction devices ordinarily must store the devices in a 
purse or wallet. This often results in a purse or wallet that 
is bulky, a nuisance to manage, and also unattractive. As 
such, the devices may typically suffer from non-use, since 
the user may remove many of the devices to preserve the 
shape or aesthetic appearance of the wallet. 

[0007] yet another disadvantage of the above conventional 

methods of managing multiple accounts, which is related 
to the different issuer formats/protocols, is that, since 
conventional financial transaction devices typically only 
store application tenant information related to one issuer, 
the information may not be recognized by the transaction 
processing system managed by a second issuer distinct 
from the first. That is, the user of the financial transaction 
device typically is only able to use the financial transaction 
device at locations identified by the issuer or acquirer of 
the transaction card. The financial transaction device may 
not be used at any other locations, since the locations not 
identified by the issuer will not recognize the application 



tenant information which is typically stored on the device 
in an issuer determined format. As such, in order to ac- 
cess multiple accounts managed by different issuers using 
different formats/protocols, the user must typically carry 
multiple cards, as noted above. 
[0008] | n addition to the above, the conventional multiple ac- 
count management systems have another disadvantage in 
that data contained on the financial transaction devices 
may not be easily updated. That is, traditional financial 
transaction devices are only "readable" devices, and not 
"writeable" devices, where the data on the device may be 
read from the device but not written to the device. More 
particularly, once the financial device is issued to the user, 
the data often may not be modified. Instead, where infor- 
mation contained on the device is to be modified, a new 
physical consumer device (e.g., transaction device) often 
needs to be issued. That is, the information stored on the 
financial transaction devices is typically not permitted to 
be changed without issuer involvement. The issuer may be 
involved, for example, by verifying compatibility of pro- 
posed new or updated information, checking conformance 
of the data to the issuer's standard formatting and size 
guidelines, and implementing the changes. Thus, addi- 



tional burdens are often placed on the issuer where it is 
desired to add unique data sets to a financial transaction 
device, or to update the data stored thereon. Further, al- 
though traditional devices employing magnetic stripe may 
be written to, such that data thereon is altered or up- 
dated, the read/write devices necessary to alter the data 
are expensive and often cost prohibitive. 
[0009] As such, storing sufficient data on a single financial trans- 
action device, which permits a user of the single device to 
complete transactions using multiple transaction accounts 
issued by different distinct issuers, does not exist. A need 
exists for a single financial transaction device, which 
stores multiple independent data sets provided by multi- 
ple distinct issuers irrespective of the format/protocol of 

the various issuers. 
Summary of Invention 

[0010] | n one exemplary embodiment of the present invention, a 
system and method is provided for a Radio Frequency op- 
erable transaction device for storing multiple distinct data 
sets of different formats on the RF transaction device. The 
method permits storage of the data sets of different for- 
mats by providing a system which permits multiple dis- 
tinct data sets to be stored on a transaction device irre- 



spective of the issuer's preferred protocol. The system 
permits the data set owner to define the protocol used or 
to permit the data set to be stored according to the re- 
quirements of the system described herein. 

[0011] The method includes the steps of: enrolling a first and 
second data set owner in a multiple account system on a 
single transaction device program; receiving at a read/ 
write device a data set corresponding to a single device 
user from at least one of the first and second data set 
owners; receiving, from the read/write device, at least a 
first distinct data of a first format at the RF transaction 
device, wherein the first data set is owned by a first 
owner; receiving, from the read/write device, at least a 
second distinct data set of a second format at the RF 
transaction device, wherein the second data set is owned 
by a second owner, and wherein the first format is differ- 
ent from the second format; storing the first data set and 
the second data set on the RF transaction device in dis- 
tinct fashion and in accordance with the first and second 
format respectively, where the first data set and the sec- 
ond data set are unique one from the other. 

[0012] | n another example, a RF transaction device comprises a 
data set management system for facilitating the storage of 



more than one data set stored on the transaction device, 
the RF transaction device comprising at least one data 
storage area configured to store a first distinct data set of 
a first format and a second distinct data set of a second 
format different from the first format. The first data set is 
associated with a first data set owner (e.g., first issuer) 
and the first data set is configured to be stored on the RF 
transaction device independent of a second data set (e.g., 
second issuer); and, the second data set is associated with 
the second owner and the second data set is configured to 
be stored on the RF transaction device independent of the 
first data set, wherein the first data set and the second 
data set are stored in accordance with the first and second 
format, respectively. 
[0013] | n y e t another exemplary embodiment of the present in- 
vention, a data management system comprises: RF trans- 
action device associated with a first data set of a first for- 
mat and a second data set of a second format, wherein 
the RF transaction device is configured to facilitate load- 
ing of the first data set without involvement of the second 
data set owner. The data management system may further 
comprise a read/write device configured to communicate 
with the RF transaction device for providing the first and 



second data sets to the transaction device. The read/write 
device may be stand-alone, or the device may be con- 
nected to a transaction processing network. The read/ 
write device may be used to load the issuer-owned data 
onto the transaction device in accordance with a data set 
owner-defined protocol. 
[0014] | n s tj|| another exemplary embodiment, the invention se- 
cures authorization from a data set owner prior to loading 
the data on the RF transaction device database. Once au- 
thorization is given, the issuer may be "enrolled" in a 
transaction device multiple account management system, 
the associated data owned by the enrolled issuer may 
then be loaded on the transaction device. The data may be 
loaded in a format recognizable by a merchant system or 
by a system maintained by the data set owner. Thus, when 
the transaction device is presented to complete a transac- 
tion, the data may be transferred to the issuer in an is- 
suer-recognized format, reducing the need to carry multi- 
ple transaction devices for each issuer. That is, the issuer 
receives the data in a data set owner recognized format 
and may process the accompanying transaction under 
data set owner previously established business as usual 
protocols. In this way, the data set owner is permitted to 



manage its issuer provided program at the owner location, 
irrespective of the management of other programs pro- 
vided by other distinct issuers enrolled in the multiple ac- 
count management system. 
Brief Description of Drawings 

[0015] a more complete understanding of the present invention 
may be derived by referring to the detailed description 
and claims when considered in connection with the Fig- 
ures, wherein like reference numbers refer to similar ele- 
ments throughout the Figures, and: 

[0016] FIG. 1 illustrates a general overview of an exemplary 

method for loading distinct data sets on a RF transaction 
device in accordance with an exemplary embodiment of 
the present invention; 

[0017] FIG. 2 illustrates a block diagram overview of an exem- 
plary system for loading distinct data sets on a RF trans- 
action device in accordance with an exemplary embodi- 
ment of the present invention; 

[0018] FIG. 3 illustrates a more detailed exemplary method for 

loading distinct data sets on a RF transaction device in ac- 
cordance with an exemplary embodiment of the present 
invention; 

[0019] FIG. 4 illustrates an exemplary data set management 



method for adding data sets in accordance with an exem- 
plary embodiment of the present invention; 

[0020] FIG. 5 an exemplary method for user self-management of 
data sets in accordance with an exemplary embodiment of 
the present invention; 

[0021] FIG. 6 an exemplary method for issuer management of 
data sets in accordance with the present invention; and 

[0022] FIG. 7 an exemplary data set selection method for use in 

completing a transaction. 
Detailed Description 

[0023] while the exemplary embodiments herein are described in 
sufficient detail to enable those skilled in the art to prac- 
tice the invention, it should be understood that other em- 
bodiments may be realized and that logical and mechani- 
cal changes may be made without departing from the 
spirit and scope of the invention. Thus, the following de- 
tailed description is presented for purposes of illustration 
only and not of limitation. 

[0024] The present invention provides a system and method for a 
RF transaction device configured to receive multiple data 
sets (e.g., "application tenants") of differing formats, 
wherein the data sets are associated with a plurality of 
distinct transaction account issuers. In this context, an 



"application tenant" may include all or any portion of any 
data sets, which are substantially correlated to an account 
issuer, which the issuer may additionally use to substan- 
tially identify an instrument user or related account. For 
example, where the account issuer provides application 
tenant information, the application tenant may include, 
inter alia, a membership identifier associated with a user 
enrolled in an issuer provided transaction account pro- 
gram, and all related subsets of data stored on the trans- 
action instrument. Where multiple application tenants are 
referred to herein, each tenant may constitute its own dis- 
tinct data set, independent of any other application tenant 
data sets. For example, each application tenant may in- 
clude a unique membership identifier and all associated 
subsets of data. Alternatively, an application tenant may 
include a membership identifier and an application for 
processing all data owned by an issuer. Thus, the data set 
or subset may include the processing application. More- 
over, differing formats, as discussed herein, include dif- 
ferences in all or any portion of the formats. As such, "ap- 
plication tenant" and "distinct data set," and data set 
"owner" and account "issuer" may be used interchangeably 
herein. 



[0025] | n addition, it should be noted that although the present 
invention is described with respect to a financial transac- 
tion instrument, the invention is not so limited. The trans- 
action instrument described herein contemplates the us- 
age of non-financial devices, such as telephone or long 
distance calling instruments (e.g., credit or stored value 
calling cards) which may be loaded with accounts associ- 
ated with multiple local exchange carriers or identification 
providers. The invention is suitable for any instrument ca- 
pable of storing distinct data sets, which may be provided 
by multiple distinct account issuers where the distinct 
data sets may be formatted one different from another. 
The account may be, for example, a loyalty, debit, credit, 
incentive, direct debit, savings, financial, membership ac- 
count or the like. While the information provided by the 
account issuers may be described as being "owned" by the 
issuers, the issuers or their designees may simply be a 
manager of the account. 

[0026] The present invention may be described herein in terms of 
functional block components, optional selections and/or 
various processing steps. It should be appreciated that 
such functional blocks may be realized by any number of 
hardware and/or software components configured to per- 



form the specified functions. For example, the present in- 
vention may employ various integrated circuit components 
(e.g., memory elements, processing elements, logic ele- 
ments, look-up tables, and/or the like), which may carry 
out a variety of functions under the control of one or more 
microprocessors or other control devices. Similarly, the 
software elements of the present invention may be imple- 
mented with any programming or scripting language such 
as C, C+ + , Java, COBOL, assembler, PERL, Visual Basic, 
SQL Stored Procedures, extensible markup language 
(XML), with the various algorithms being implemented 
with any combination of data structures, objects, pro- 
cesses, routines or other programming elements. Further, 
it should be noted that the present invention may employ 
any number of conventional techniques for data transmis- 
sion, signaling, data processing, network control, and/or 
the like. 

[0027] As used herein, the terms "user," "end user," "consumer," 
"customer" or "participant" may be used interchangeably 
with each other, and each shall mean any person, entity, 
machine, hardware, software and/or business. Further- 
more, the terms "business" or "merchant" may be used in- 
terchangeably with each other and shall mean any person, 



entity, machine, hardware, software or business. Further 
still, the merchant may be any person, entity, software 
and/or hardware that is a provider, broker and/or any 
other entity in the distribution chain of goods or services. 
For example, the merchant may be a ticket/event agency 
(e.g., Ticketmaster, Telecharge, Clear Channel, brokers, 
agents). 

[0028] The systems and/or components of the systems discussed 
herein may also include one or more host servers or other 
computing systems including a processor configured to 
process digital data, a memory coupled to the processor 
for storing digital data, an input digitizer coupled to the 
processor for inputting digital data, an application pro- 
gram stored in the memory and accessible by the proces- 
sor for directing processing of digital data by the proces- 
sor, a display coupled to the processor and memory for 
displaying information derived from digital data processed 
by the processor and a plurality of databases, the 
databases including client data, merchant data, financial 
institution data and/or like data that could be used in as- 
sociation with the present invention. The user computer 
and other systems described herein can be in a home or 
business environment with access to a network. In an ex- 



emplary embodiment, access is through the Internet 
through a commercially available web-browser software 
package. 

[0029] Communication between various elements of the present 
invention is accomplished through any suitable communi- 
cation means, such as, for example, a telephone network, 
intranet, Internet, point of interaction device (point of sale 
device, personal digital assistant, cellular phone, kiosk, 
etc.), online communications, off-line communications, 
wireless communications, and/or the like. One skilled in 
the art may also appreciate that, for security reasons, any 
databases, systems, or components of the present inven- 
tion may consist of any combination of databases or com- 
ponents at a single location or at multiple locations, 
wherein each database or system includes any of various 
suitable security features, such as firewalls, access codes, 
encryption, decryption, compression, decompression, 
and/or the like. 

[0030] The systems may be suitably coupled to the network via 
data links. A variety of conventional communications me- 
dia and protocols may be used for data links. For exam- 
ple, a connection to an Internet Service Provider (ISP) over 
the local loop as is typically used in connection with stan- 



dard modem communication, cable modem, Dish net- 
works, ISDN, Digital Subscriber Line (DSL), or various 
wireless communication methods. The merchant system 
might also reside within a local area network (LAN) that 
interfaces to the network via a leased line (Tl, D3, etc.). 
Such communication methods are well known in the art 
and are covered in a variety of standard texts. See, e.g., 
Gilbert Held, "Understanding Data Communica- 
tions"(1996), hereby incorporated by reference. 
[0031] The computing units may be connected with each other 
via a data communication network. The network may be a 
public network and assumed to be insecure and open to 
eavesdroppers. In the illustrated implementation, the net- 
work may be embodied as the Internet. In this context, 
the computers may or may not be connected to the Inter- 
net at all times. For instance, the customer computer may 
employ a modem to occasionally connect to the Internet, 
whereas the bank-computing center might maintain a 
permanent connection to the Internet. Specific information 
related to the protocols, standards, and application soft- 
ware utilized in connection with the Internet may not be 
discussed herein. For further information regarding such 
details, see, for example, Dilip Naik, "Internet Standards 



and Protocols" (1998); "Java 2 Complete," various authors 
(Sybex 1999); Deborah Ray and Eric Ray, "Mastering HTML 
4.0" (1997); Loshin, "TCP/IP Clearly Explained" (1997). All 
of these texts are hereby incorporated by reference. 
[0032] | t mav De appreciated that many applications of the 

present invention could be formulated. One skilled in the 
art may appreciate that a network may include any system 
for exchanging data or transacting business, such as the 
Internet, an intranet, an extranet, WAN, LAN, satellite 
communications, and/or the like. It is noted that the net- 
work may be implemented as other types of networks, 
such as an interactive television (ITV) network. The users 
may interact with the system via any input device such as 
a keyboard, mouse, kiosk, personal digital assistant, 
handheld computer (e.g., Palm Pilot®), cellular phone and/ 
or the like. Similarly, the invention could be used in con- 
junction with any type of personal computer, network 
computer, workstation, minicomputer, mainframe, or the 
like running any operating system such as any version of 
Windows, Windows NT, Windows2000, Windows 98, Win- 
dows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the 
like. Moreover, although the invention is frequently de- 
scribed herein as being implemented with TCP/IP commu- 



nications protocols, it may be readily understood that the 
invention could also be implemented using IPX, Appletalk, 
IP-6, NetBIOS, OSI or any number of existing or future 
protocols. Moreover, the present invention contemplates 
the use, sale or distribution of any goods, services or in- 
formation over any network having similar functionality 
described herein. 
[0033] | n accordance with various embodiments of the invention, 
the Internet Information Server, Microsoft Transaction 
Server, and Microsoft SQL Server, are used in conjunction 
with the Microsoft operating system, Microsoft NT web 
server software, a Microsoft SQL database system, and a 
Microsoft Commerce Server. Additionally, components 
such as Access or SQL Server, Oracle, Sybase, Informix 
MySQL, Interbase, etc., may be used to provide an ADO- 
compliant database management system. The term "web- 
page" as it is used herein is not meant to limit the type of 
documents and applications that might be used to interact 
with the user. For example, a typical website might in- 
clude, in addition to standard HTML documents, various 
forms, Java applets, Javascript, active server pages (ASP), 
common gateway interface scripts (CGI), extensible 
markup language (XML), dynamic HTML, cascading style 



sheets (CSS), helper applications, plug-ins, and/or the 
like. 

[0034] The financial transaction instrument (e.g., smart card, 

magnetic stripe card, bar code card, optical card, biomet- 
ric device, embossed card, radio frequency card or 
transponder and/or the like) may communicate to the 
merchant, information from one or more data sets associ- 
ated with the financial transaction instrument. In one ex- 
ample, membership data and credit card data associated 
with an account or card may be transmitted using any 
conventional protocol for transmission and/or retrieval of 
information from an account or associated transaction 
card (e.g., credit, debit, loyalty, etc.). In one exemplary 
embodiment, the transaction instrument may be config- 
ured to communicate via RF signals. As such, the data 
contained on the instrument may be communicated via 
radio frequency signals. 

[0035] a financial transaction instrument may include one or 

more physical devices used in carrying out various finan- 
cial transactions. For example, a financial transaction in- 
strument may include a rewards card, charge card, credit 
card, debit card, prepaid card, telephone card, smart card, 
magnetic stripe card, radio frequency card/transponder 



and/or the like. In yet another exemplary embodiment of 
the present invention, a financial transaction instrument 
may be an electronic coupon, voucher, and/or other such 
instrument. 

[0036] The financial transaction instrument in accordance with 
this invention may be used to pay for acquisitions, obtain 
access, provide identification, pay an amount, receive 
payment, redeem reward points and/or the like. In the ra- 
dio frequency ("RF") embodiments of the transaction in- 
strument, instrument-to-instrument transactions may 
also be performed. See, for example, Sony's "Near Field 
Communication" ("NFC") emerging standard, which is 
touted as operating on 13.56 MHz and allowing the trans- 
fer of any kind of data between NFC enabled devices and 
across a distance of up to twenty centimeters. See also, 
Bluetooth chaotic network configurations; described in 
more detail at 

http://www.palowireless.com/infotooth/whatis.asp, which 
is incorporated herein by reference. Furthermore, data on 
a first RF device may be transmitted directly or indirectly 
to another RF device to create a copy of all or part of the 
original device. 
[0037] Furthermore, financial transaction instrument as de- 



scribed herein may be associated with various applica- 
tions, which allow the financial transaction instruments to 
participate in various programs, such as, for example, 
loyalty programs. A loyalty program may include one or 
more loyalty accounts. Exemplary loyalty programs in- 
clude frequent flyer miles, on-line points earned from 
viewing or purchasing products or websites on-line and 
programs associated with diner's cards, credit cards, debit 
cards, hotel cards, and/or the like. Generally, the user is 
both the owner of the transaction card account and the 
participant in the loyalty program; however, this associa- 
tion is not necessary. For example, a participant in a loy- 
alty program may gift loyalty points to a user who pays for 
a purchase with his own transaction account, but uses the 
gifted loyalty points instead of paying the monetary value. 
[0038] For more information on loyalty systems, transaction sys- 
tems, and electronic commerce systems, see, for example, 
U.S. Utility Patent Application Serial No. 10/304,251, filed 
on November 26, 2002, by inventors Antonucci, et al., and 
entitled "System and Method for Transfer of Loyalty 
Points" U.S. Continuation-ln-Part Patent Application Serial 
No. 10/378,456, filed on March 3, 2003, by inventors An- 
tonucci, et al., and entitled "System and Method for the 



Real-Time Transfer of Loyalty Points Between Accounts" 
U.S. Patent Application Serial No. 09/836,213, filed on 
April 17, 2001, by inventors Voltmer, et al., and entitled 
"System And Method For Networked Loyalty Program"; U.S. 
Continuation-ln-Part Patent Application Serial No. 
10/027,984, filed on December 20, 2001, by inventors 
Ariff, et al., and entitled "System And Method For Net- 
worked Loyalty Program"; U.S. Continuation-ln-Part Patent 
Application Serial No. 10/010,947, filed on November 6, 
2001, by inventors Haines, et al., and entitled "System 
And Method For Networked Loyalty Program" U.S. Contin- 
uation-ln-Part Patent Application Serial No. 10/084,744, 
filed on February 26, 2002, by inventors Bishop, et al., 
and entitled "System And Method For Securing Data 
Through A PDA Portal" the Shop AMEX™ system as dis- 
closed in Serial No. 60/230,190, filed September 5, 2000; 
the Loyalty As Currency™ and Loyalty Rewards Systems 
disclosed in Serial No. 60/197,296, filed on April 14, 
2000, Serial No. 60/200,492, filed April 28, 2000, Serial 
No. 60/201,114, filed May 2, 2000; a digital wallet system 
disclosed in U.S. Serial No. 09/652,899, filed August 31, 
2000; a stored value card as disclosed in Serial No. 
09/241,188, filed on February 1, 1999; a system for facil- 



itating transactions using secondary transaction numbers 
disclosed in Serial No. 09/800,461, filed on March 7, 
2001, and also in related provisional applications Serial 
No. 60/187,620, filed March 7, 2000, Serial No. 
60/200,625, filed April 28, 2000, and Serial No. 
60/213,323, filed May 22, 2000, all of which are herein 
incorporated by reference. Other examples of online loy- 
alty systems are disclosed in Netcentives U.S. Patent No. 
5,774,870, issued on June 30, 1998, and U.S. Patent No. 
6,009,412, issued on December 29, 1999, both of which 
are hereby incorporated by reference. 
[0039] Further still, a "code," "account", "account number," "iden- 
tifier," "loyalty number" or "membership identifier," as 
used herein, includes any device, code, or other identifier/ 
indicia suitably configured to allow the consumer to inter- 
act or communicate with the system, such as, for exam- 
ple, authorization/access code, personal identification 
number (PIN), Internet code, other identification code, 
and/or the like that is optionally located on a rewards 
card, charge card, credit card, debit card, prepaid card, 
telephone card, smart card, magnetic stripe card, bar code 
card, radio frequency card and/or the like. The account 
number may be distributed and stored in any form of 



plastic, electronic, magnetic, radio frequency, audio and/ 
or optical device capable of transmitting or downloading 
data from itself to a second device. A customer account 
number may be, for example, a sixteen-digit credit card 
number, although each credit provider has its own num- 
bering system, such as the fifteen-digit numbering sys- 
tem used by an exemplary loyalty system. Each company's 
credit card numbers comply with that company's stan- 
dardized format such that the company using a sixteen- 
digit format may generally use four spaced sets of num- 
bers, as represented by the number "0000 0000 0000 
0000." The first five to seven digits are reserved for pro- 
cessing purposes and identify the issuing bank, card type 
and etc. In this example, the last sixteenth digit is used as 
a sum check for the sixteen-digit number. The intermedi- 
ary eight-to-ten digits are used to uniquely identify the 
customer. In addition, loyalty account numbers of various 
types may be used. 
[0040] Further yet, the "transaction information" in accordance 
with this invention may include the nature or amount of 
transaction, as well as, a merchant, user, and/or issuer 
identifier, security codes, or routing numbers, and the 
like. In various exemplary embodiments of the present in- 



vention, one or more transaction accounts may be used to 
satisfy or complete a transaction. For example, the trans- 
action may be only partially completed using the transac- 
tion account(s) correlating to the application tenant infor- 
mation stored on the transaction instrument with the bal- 
ance of the transaction being completed using other 
sources. Cash may be used to complete part of a transac- 
tion and the transaction account associated with a user 
and the transaction instrument, may be used to satisfy the 
balance of the transaction. Alternatively, the user may 
identify which transaction account, or combination of 
transaction accounts, stored on the transaction instru- 
ment the user desires to complete the transaction. Any 
known or new methods and/or systems configured to ma- 
nipulate the transaction account in accordance with the 
invention may be used. 
[0041] | n various exemplary embodiments, the financial transac- 
tion instrument may be embodied in form factors other 
than, for example, a card-like structure. As already men- 
tioned, the financial transaction instrument may comprise 
an RF transponder, a speed pass, store discount card, or 
other similar device. Furthermore, the financial transac- 
tion instrument may be physically configured to have any 



decorative or fanciful shape including key chains, jewelry 
and/or the like. The financial transaction instrument may 
furthermore be associated with coupons. A typical RF de- 
vice which may be used by the present invention is dis- 
closed in U.S. Application Serial No. 10/192,488, entitled 
"System And Method For Payment Using Radio Frequency 
Identification In Contact And Contactless Transactions," 
and its progeny, which are all commonly assigned, and 
which are all incorporated herein by reference.As used 
herein, the term "data set" may include any set of infor- 
mation and/or the like which may be used, for example, 
in completing a transaction. For example, data sets may 
include information related to credit cards, debit cards, 
membership clubs, loyalty programs, speed pass ac- 
counts, rental car memberships, frequent flyer programs, 
coupons, tickets and/or the like. This information may in- 
clude membership identifiers, account number(s), per- 
sonal information, balances, past transaction details, ac- 
count issuer routing number, cookies, identifiers, security 
codes, and/or any other information. The data set may 
additionally include an issuer defined management pro- 
cess for determining which subsets of data are to be pro- 
vided to an issuer or merchant. In some instances, a data 



set may be associated with one or more account numbers 
corresponding to accounts maintained by the account is- 
suer. A data set may contain any type of information 
stored in digital format. For example, a data set may in- 
clude account numbers, programs/applications, scripts, 
cookies, instruments for accessing other data sets, and/or 
any other information. 
[0042] various information and data are described herein as be- 
ing "stored." In this context, "stored" may mean that the 
information is kept on a database. In accordance with the 
invention, a database may be any type of database, such 
as relational, hierarchical, object-oriented, and/or the 
like. Common database products that may be used to im- 
plement the databases include DB2 by IBM (White Plains, 
New York), any of the database products available from 
Oracle Corporation (Redwood Shores, California), Mi- 
crosoft Access or MSSQL by Microsoft Corporation 
(Redmond, Washington), or any other database product. A 
database may be organized in any suitable manner, in- 
cluding as data tables or lookup tables. Association of 
certain data may be accomplished through any data asso- 
ciation technique known and/or practiced in the art. For 
example, the association may be accomplished either 



manually or automatically. Automatic association tech- 
niques may include, for example, a database search, a 
database merge, GREP, ACREP, SQL, and/or the like. The 
association step may be accomplished by a database 
merge function, for example, using a "key field" in each of 
the manufacturer and retailer data tables. A "key field" 
partitions the database according to the high-level class 
of objects defined by the key field. For example, a certain 
class may be designated as a key field in both the first 
data table and the second data table, and the two data ta- 
bles may then be merged on the basis of the class data in 
the key field. In this embodiment, the data corresponding 
to the key field in each of the merged data tables is 
preferably the same. However, data tables having similar, 
though not identical, data in the key fields may also be 
merged by using AGREP, for example. 
[0043] Although the same owner may own all data sets associ- 
ated with a particular financial transaction instrument, it is 
contemplated that in general, some of the data sets 
stored on the financial transaction instrument have differ- 
ent owners. Furthermore, the storage of data sets is con- 
figured to facilitate independent storage and management 
of the data sets on the financial transaction instrument. 



Further still, the data sets may be stored in distinct differ- 
ing formats provided by the distinct issuer or data set 
owner (also called "issuer," herein). The owners of data 
sets may include different individuals, entities, busi- 
nesses, corporations, software, hardware, and/or the like. 
However, one skilled in the art will appreciate that the 
owners may also include different divisions or affiliates of 
the same corporation or entity. 
[0044] As discussed above, many issuers of existing financial 

transaction instruments utilize predetermined formats for 
account numbers, data and/or applications stored in as- 
sociation with the financial transaction instrument. Simi- 
larly, the data storage media associated with these finan- 
cial transaction instruments is typically configured to ac- 
commodate specific predetermined data formats. Thus, 
since the data format associated with a first issuer is often 
different from a data format of a second issuer, storage of 
multiple distinct data of differing formats on a single de- 
vice provides complications for conventional systems. This 
is true since, each issuer typically maintains an account 
processing system that uses a processing protocol differ- 
ent from other issuers, and the information stored on the 
transaction card relative to the issuer must be formatted 



accordingly. As such, to ensure the security and integrity 
of the issuer-owned data, the loading of data on a trans- 
action instrument is typically performed by an issuer or a 
third-party provider who typically uploads all related and 
similarly formatted data sets onto the transaction instru- 
ment. However, since the third party may typically only be 
authorized by the issuer to load issuer-owned data of 
similar format onto an issuer-provided transaction device, 
including differently formatted data sets on a single 
transaction device by the third party is often not permit- 
ted. More particularly, independent owners of data sets 
are often reluctant to conform their data set formats to a 
"standard format" because of the security advantages of 
maintaining a separate, distinct, often secreted format. 
[0045] | n contrast, and in accordance with an exemplary embodi- 
ment of the present invention, the format of the informa- 
tion stored in the present invention may vary from one 
data set to another. That is, the present invention permits 
the data to be stored on the financial transaction instru- 
ment in any format, and more particularly, in any format 
recognizable by the data owner/transaction instrument 
issuer. Thus, as noted, each data set may be used for a 
very wide variety of purposes including storage of appli- 



cations, raw data, cookies, coupons, membership data, 
account balances, loyalty information, and/or the like. 

[0046] | n accordance with one aspect of the present invention, 
any suitable data storage technique may be utilized to 
store data without a standard format. Data sets may be 
stored using any suitable technique, including, for exam- 
ple, storing individual files using an ISO/IEC 7816-4 file 
structure; implementing a domain whereby a dedicated 
file is selected that exposes one or more elementary files 
containing one or more data sets; using data sets stored 
in individual files using a hierarchical filing system; data 
sets stored as records in a single file (including compres- 
sion, SQL accessible, hashed via one or more keys, nu- 
meric, alphabetical by first tuple, etc.); block of binary 
(BLOB); stored as ungrouped data elements encoded using 
ISO/IEC 7816-6 data elements; stored as ungrouped data 
elements encoded using ISO/IEC Abstract Syntax Notation 
(ASN.l) as in ISO/IEC 8824 and 8825; and/or other pro- 
prietary techniques that may include fractal compression 
methods, image compression methods, etc. 

[0047] | n 0 ne exemplary embodiment, the ability to store a wide 
variety of information in different formats is facilitated by 
storing the information as a Block of Binary (BLOB). Thus, 



any binary information can be stored in a storage space 
associated with a data set. As discussed above, the binary 
information may be stored on the financial transaction in- 
strument or external to but affiliated with the financial 
transaction instrument. The BLOB method may store data 
sets as ungrouped data elements formatted as a block of 
binary via a fixed memory offset using either fixed stor- 
age allocation, circular queue techniques, or best prac- 
tices with respect to memory management (e.g., paged 
memory, memory recently used, etc.). By using BLOB 
methods, the ability to store various data sets that have 
different formats facilitates the storage of data associated 
with the financial transaction instrument by multiple and 
unrelated owners of the data sets. For example, a first 
data set which may be stored may be provided by a first 
issuer, a second data set which may be stored may be 
provided by an unrelated second issuer, and yet a third 
data set which may be stored, may be provided by a third 
issuer unrelated to the first and second issuers. Each of 
these three exemplary data sets may contain different in- 
formation that is stored using different data storage for- 
mats and/or techniques. Further, each data set may con- 
tain subsets of data, which also may be distinct from 



other subsets. 

[0048] Even further, where the invention contemplates the use of 
a self-service user interaction device. In this context, the 
self-service user interaction device may be any device 
suitable for interacting with a transaction instrument, and 
receiving information from the transaction instrument 
user and providing the information to a merchant, account 
issuer, account manager, data set owner, merchant point 
of sale, and the like. For example, the self-service user 
interaction device may be a stand-alone read write device, 
self-service Kiosk, merchant point of sale, read/write de- 
vice, and the like. In one example, the self-service user 
interaction device may be configured to communicate in- 
formation to and from the transaction device and to ma- 
nipulate the data sets stored thereon. The self-service in- 
teraction device may be in communication with the vari- 
ous components of the invention using any communica- 
tions protocol. 

[0049] | n general, systems and methods disclosed herein are 
configured to facilitate the loading of multiple distinct 
data sets onto a RF transaction device. With reference to 
FIG. 1, an exemplary method 100 according to the present 
invention is shown. Method 100 may include, for example, 



issuing a RF transaction device to a user (step 110), en- 
rolling multiple data set owners in a multiple account 
transaction device program (step 112) and loading distinct 
data sets onto the transaction device, where the data sets 
may be owned by unrelated account issuers (step 116). 
Once the data is appropriately loaded, the RF transaction 
device user may present the RF transaction device (step 
114) to a merchant system for completion of a transaction 
(step 122). 

[0050] The system may be further configured such that, during 

an exemplary transaction, data sets associated with the fi- 
nancial transaction instrument may be managed. For ex- 
ample, the user may be prompted (e.g., on a screen, by 
electronic voice, by a store clerk, by a signal and/or the 
like) as to the possibility of adding, for example, a loyalty 
account to the same financial transaction instrument and 
the user may also be presented with terms and/or condi- 
tions in a similar or different manner. The user may be 
prompted at any time during the transaction, but prefer- 
ably the user is prompted at the completion of the trans- 
action. If the user accepts the invitation to add data to the 
financial transaction instrument, a new data set may be 
added (step 116). If the data is to be added, the stand- 



alone device may be configured to provide any account 
information (e.g., account identifier, security code, data 
owner routing number, etc.) to the transaction device for 
storage thereon. The stand-alone may locate an appropri- 
ate database location on transaction instrument for stor- 
ing the added data. The stand-alone device facilitates 
storage of the data in a distinct location on the transac- 
tion device database, where the data is stored indepen- 
dently of any other data. In a preferred embodiment of the 
invention, the data is added to a database location on the 
transaction device, which reserved for independently stor- 
ing all data owned by a particular data set owner. Alterna- 
tively, the data may be stored in a distinct location on the 
transaction device, which is a separate location than is 
used to store any other data set. Further still, the data set 
is stored in accordance with any storage protocol permit- 
ting the data to be stored and retrieved independently of 
other data. 

[0051] The adding of the data may be verified by the issuer, prior 
to making the modifications. The issuer may verify the 
data by, for example, running a verifying protocol for de- 
termining if the information is properly stored or format- 
ted. If verified, all databases containing the data set to be 



updated or a mirror image of the data set to be updated 
are modified in accordance with the user or issuer pro- 
vided instructions, and/or the issuer defined data storage 
protocol or format. 
[0052] | n one exemplary embodiment, multiple account issuers 
may be enrolled in a multiple account management pro- 
gram using a financial transaction instrument in accor- 
dance with the invention (step 112). For example, permis- 
sion for adding account issuer owned data may be ob- 
tained from the data set owner. The data set owner may 
then be requested to provide account information to be 
stored on a transaction instrument. The data set owner 
may then provide account information relative to a distinct 
user account for loading onto the transaction instrument 
in accordance with the present invention. The issuers may 
be enrolled prior to issuance of the instrument or the is- 
suers may be enrolled after issuance. By enrolling in the 
management program, the issuer may provide authoriza- 
tion for including the issuer-owned data on the financial 
transaction instrument. The issuer-owned data may be in- 
cluded (e.g., added) on the transaction instrument using a 
stand-alone interaction device, merchant system, or user 
personal computer interface upon presentment of the 



transaction device to the stand-alone interaction device 
290 (step 114), shown on FIG. 2. The stand-alone interac- 
tion device may add the issuer-owned data while preserv- 
ing a format recognizable by an issuer account manage- 
ment system. For example, the stand-alone device may 
identify an appropriate header or trailer associated with 
the data and adds the data accordingly. The stand-alone 
may add the data using any adding instruction or protocol 
as provided by the data set owner so that the resulting 
added data is stored in a format recognizable by the data 
set owner system. In this way, the stand-alone device may 
add the data while maintaining the data set owner's for- 
mat. Alternatively, the interaction device may store the is- 
suer-owned data on the transaction instrument in any 
format, provided that the issuer-owned data is provided 
to the issuer system (or to merchant system) in an issuer 
system (or merchant system) recognizable format. 
[0053] it should be noted, that the financial transaction instru- 
ment may be issued with or without one or more data sets 
stored thereon. The financial transaction instrument may 
be issued using various techniques and practices now 
known or hereinafter developed wherein an instrument is 
prepared (e.g., embossed and/or loaded with data) and 



made available to a user for effecting transactions. Al- 
though the present invention may contemplate adding 
data sets (step 116) before issuing a financial transaction 
instrument (step 110), in various exemplary embodi- 
ments, by way of illustration, the data sets are described 
herein as being added (step 116) after issuance (step 
110). 

[0054] At any time after issuance (step 110) of the financial 

transaction instrument, or when the data is successfully 
added (step 116), the financial transaction instrument may 
be used in a commercial transaction. In one exemplary 
embodiment of the present invention, a user communi- 
cates with a merchant, indicates a desire to participate in 
an issuer provided consumer program. The user may 
communicate with the merchant by, for example, present- 
ing the transaction instrument to the merchant and in- 
dicting a desire to complete a transaction. The user may 
indicate his desire to complete a transaction using any 
conventional process used by the merchant. The user may 
further indicate that the user wishes to complete the 
transaction using the financial transaction instrument. 

[0055] During completion of the transaction, the user may 

present the financial transaction instrument to a merchant 



system (step 122). The financial transaction instrument is 
configured to communicate with the merchant, using any 
conventional method for facilitating a transaction over a 
network. 

[0056] As stated above, in various embodiments of the present 
invention, the data can be stored without regard to a 
common format. However, in one exemplary embodiment 
of the present invention, the data set (e.g., BLOB) may be 
annotated in a standard manner when provided for ma- 
nipulating the data onto the financial transaction instru- 
ment. The annotation may comprise a short header, 
trailer, or other appropriate indicator related to each data 
set that is configured to convey information useful in 
managing the various data sets. For example, the annota- 
tion may be called a "condition header," "header," "trailer," 
or "status," herein, and may comprise an indication of the 
status of the data set or may include an identifier corre- 
lated to a specific issuer or owner of the data. In one ex- 
ample, the first three bytes of each data set BLOB may be 
configured or configurable to indicate the status of that 
particular data set (e.g., ADD, LOADED, INITIALIZED, 
READY, BLOCKED, ACTIVE, INACTIVE). Subsequent bytes of 
data may be used to indicate for example, the identity of 



the issuer, user, transaction/membership account identi- 
fier or the like. The use condition annotations are further 
discussed herein. 

[0057] The data set annotation may also be used for other types 
of status information as well as various other purposes. 
For example, the data set annotation may include security 
information establishing access levels. The access levels 
may, for example, be configured to permit only certain in- 
dividuals, levels of employees, companies, or other enti- 
ties to access data sets, or to permit access to specific 
data sets based on the transaction, merchant, issuer, user 
or the like. Furthermore, the security information may re- 
strict/permit only certain actions such as accessing data 
sets. In one example, the data set annotation indicates 
that only the data set owner or the user are permitted to 
access or add a data set, various identified merchants are 
permitted to access the data set for reading, and others 
are altogether excluded from accessing the data set. 
However, other access restriction parameters may also be 
used allowing various entities to access a data set with 
various permission levels as appropriate. 

[0058] The data, including the header or trailer may be received 
from a data set owner via any communication method de- 



scribed herein. The header or trailer may be appended to 
a data set to be modified, added or deleted, to indicate 
the action to be taken relative to the data set. The data set 
owner may provide the to a stand-alone interaction device 
configured to add the data in accordance with the header 
or trailer. As such, in one exemplary embodiment, the 
header or trailer is not stored on the transaction device 
along with the associated issuer-owned data but instead 
the appropriate action may be taken by providing to the 
transaction instrument user at the stand-alone device, the 
appropriate option for the action to be taken. However, 
the present invention contemplates a data storage ar- 
rangement wherein the header or trailer, or header or 
trailer history, of the data is stored on the transaction in- 
strument in relation to the appropriate data. 
[0059] | n various exemplary embodiments, the step of adding 

data sets may be repeated. For example, first, second, and 
additional data sets may be added (step 130) to the finan- 
cial transaction instrument in any order. In one exemplary 
embodiment of the present invention, the first data set is 
owned by a first data set owner (i.e., first issuer) and the 
second data set is owned by a second data set owner (i.e., 
second issuer). 



[0060] For example, permission for adding account issuer owned 
data may be obtained from the data set owner. The data 
set owner may then be requested to provide account in- 
formation to be stored on a transaction instrument. The 
data set owner may then provide account information rel- 
ative to a distinct user account for loading onto the trans- 
action instrument in accordance with the present inven- 
tion. The issuers may be enrolled prior to issuance of the 
instrument or the issuers may be enrolled after issuance. 
By enrolling in the management program, the issuer may 
provide authorization for including the issuer-owned data 
on the financial transaction instrument. The issuer-owned 
data may be included (e.g., added, deleted, modified, 
augmented, etc.) on the transaction instrument using a 
stand-alone interaction device, merchant system, or user 
personal computer interface upon presentment of the 
transaction device to the stand-alone interaction device 
290 (step 114). The stand-alone interaction device may 
manipulate the issuer-owned data while preserving a for- 
mat recognizable by an issuer account management sys- 
tem. For example, the stand-alone device may identify the 
appropriate header or trailer associated with the data and 
add, delete or modify the data accordingly. The stand- 



alone may manipulate the data using any manipulation in- 
struction or protocol as provided by the data set owner so 
that the resulting manipulated data is in a format recog- 
nizable by the data set owner system. In this way, the 
stand-alone device may manipulate the data while main- 
taining the data set owner's format. Alternatively, the in- 
teraction device may store the issuer-owned data on the 
transaction instrument in any format, provided that the 
issuer-owned data is provided to the issuer system (or to 
merchant system) in an issuer system (or merchant sys- 
tem) recognizable format. 
[0061] it should be noted, that the financial transaction instru- 
ment may be issued with or without one or more data sets 
stored thereon. The financial transaction instrument may 
be issued using various techniques and practices now 
known or hereinafter developed wherein an instrument is 
prepared (e.g., embossed and/or loaded with data) and 
made available to a user for effecting transactions. Al- 
though the present invention may contemplate adding 
data sets (step 130) before issuing a financial transaction 
instrument (step 110), in various exemplary embodi- 
ments, by way of illustration, the data sets are described 
herein as being added (step 116) after issuance (step 



110). 

[0062] | t should be noted, that the RF transaction device may be 
issued with or without one or more data sets stored 
thereon. The RF transaction device may be issued using 
various techniques and practices now known or here- 
inafter developed wherein a device is prepared (e.g., em- 
bossed and/or loaded with data) and made available to a 
user for effecting transactions. Although the present in- 
vention may contemplate loading data sets onto the 
transaction device (step 116) before or during issuance of 
a RF transaction device (step 110), in various exemplary 
embodiments, by way of illustration, the data sets are de- 
scribed herein as being loaded after issuance. 

[0063] At any time after issuance (step 110) of the financial 

transaction instrument, the financial transaction instru- 
ment may be used in a commercial transaction. In one ex- 
emplary embodiment of the present invention, a user 
communicates with a merchant, indicates a desire to par- 
ticipate in an issuer provided consumer program. The user 
may communicate with the merchant by, for example, 
presenting the transaction instrument to the merchant 
and indicting a desire to complete a transaction. The user 
may indicate his desire to complete a transaction using 



any conventional process used by the merchant. The user 
may further indicate that the user wishes to complete the 
transaction using the financial transaction instrument. 

[0064] During completion of the transaction, the user may 

present the financial transaction instrument to a merchant 
system. The financial transaction instrument is configured 
to communicate with the merchant, using any conven- 
tional method for facilitating a transaction over a network. 

[0065] The RF transaction device (e.g., smart card, magnetic 

stripe card, bar code card, optical card, biometric device, 
radio frequency card or transponder and/or the like) may 
communicate, to the merchant, information from one or 
more data sets associated with the RF transaction device. 
In one example, membership data and credit card data 
associated with an account or card may be transmitted 
using any conventional protocol for transmission and/or 
retrieval of information from an account or associated 
transaction card (e.g., credit, debit, loyalty, etc.). In one 
exemplary embodiment, the transaction device may be 
configured to communicate via RF signals. As such, the 
data contained on the device may be communicated via 
radio frequency signals. 

[0066] with reference now to FIG. 2, in one exemplary embodi- 



ment of the present invention, a multiple data set transac- 
tion device system ("management system") 200 com- 
prises, for example, a merchant system 220, various is- 
suer systems 230, and a RF transaction device 240. Man- 
agement system 200 may further be accessed by a user 
201 on a user computer 250 or via a transaction device 
such as, for example, kiosk 270, stand-alone interaction 
device 290, automated teller, or the like. In these exam- 
ples, communications between user computer 250 or 
kiosk 270 and merchant system 220 or issuer systems 
230 may take place via, for example, a network 260. In 
various embodiments, merchant system 220, user com- 
puter 250 and/or kiosk 270 are configured to communi- 
cate with RF transaction device 240. For example, com- 
munication with the RF transaction device 240 may be fa- 
cilitated by a read/write device 280, such as a merchant 
point of sale, merchant RFID reader, kiosk, computer in- 
terface, or the like, configured to receive information pro- 
vided by the RF transaction device 240. Network 280 may 
be configured to provide public access for operation of he 
system 200. 

[0067] | n general, merchant system 220 is configured to interact 
with a user 201 attempting to complete a transaction, and 



to communicate transaction data to one or more of issuer 
systems 230. Issuer systems 230 are configured to inter- 
act with RF transaction device 240 to receive and/or ex- 
change data facilitating a transaction. Merchant system 
220 may be operated, controlled and/or facilitated by any 
merchant that accepts payment via a transaction device. 
Merchant system 220 is configured to facilitate interaction 
with user 201, which may be any person, entity, software 
and/or hardware. The user 201 may communicate with 
the merchant in person (e.g., at the box office), or elec- 
tronically (e.g., from a user computer 250 via network 
260). During the interaction, the merchant may offer 
goods and/or services to the user 201. The merchant may 
also offer the user 201 the option of completing the 
transaction using a RF transaction device 240. Merchant 
system 220 may include a computer system 222 that may 
offer the option via a suitable website, web pages or other 
Internet-based graphical user interface that is accessible 
by users. The term "webpage" as it is used herein is not 
meant to limit the type of documents and applications 
that might be used to interact with the user. Any type of 
user interface wherein the user may be provided options 
for adding data to the transaction device may be used. 



[0068] Each user 201 may be equipped with a computing system 
to facilitate online commerce transactions. For example, 
the user 201 may have a computing unit in the form of a 
personal computer (e.g., user computer 250), although 
other types of computing units may be used including 
laptops, notebooks, hand held computers, set-top boxes, 
and/or the like. The merchant system 220 may have a 
computing unit 222 implemented in the form of a com- 
puter-server, although other implementations are possi- 
ble. The issuer system 230 may have a computing center 
such as a mainframe computer. However, the issuer com- 
puting center may be implemented in other forms, such 
as a mini-computer, a PC server, a network set of com- 
puters, or the like. 

[0069] issuer system 230 may be configured to manipulate a 

transaction account associated with the corresponding is- 
suer-owned data stored on the transaction device 240 (or 
database 282, discussed below) in accordance with a re- 
lated transaction. For example, the issuer system 230 may 
receive "transaction information" and manipulate an ac- 
count status or balance in accordance with the informa- 
tion received. In accordance with the transaction amount, 
the issuer system 230 may, for example, diminish a value 



available for completing a transaction associated with the 
account, or the issuer system 230 may alter the informa- 
tion relative to the account user (e.g., demographics, per- 
sonal information, etc.). 

[0070] it should be noted that issuer systems 230 may also be 
configured to interact with RF transaction device 240, di- 
rectly or indirectly via stand-alone interaction device 290, 
to individually provide data sets for loading on RF trans- 
action device 240. In some embodiments, the data sets 
may be provided to the stand-alone device 290 via net- 
work 260 for storing on RF transaction device 240 when 
the transaction device is presented. In other embodi- 
ments, issuer systems 230 may store data set information 
within their own systems, which may communicate with 
the RF transaction device via user computer 250, kiosk 
270, or merchant system 220. In the embodiments de- 
scribed, the issuer system 230 may be configured to push 
the data set to the RF transaction device 240, via the 
stand-alone interaction device 240 or the merchant sys- 
tem 220, kiosk 270, interaction device 290 or computer 
250 which may be configured to pull such information 
from the issuer system 230. 

[0071] | n addition, the data may be loaded onto the transaction 



device 240 using, for example, a stand-alone interaction 
device 290 configured to communicate with at least one 
of the issuer systems 230 which may or may not be con- 
figured to communicate with a merchant system 220. The 
interaction device 290 may communicate with the issuer 
systems 230 using any of the aforementioned communi- 
cation protocols, techniques and data links. The commu- 
nication between the stand-alone interaction device 290 
and the issuer system 230 may be facilitated by a network 
260. In an exemplary embodiment, the network 260 may 
be secure against unauthorized eavesdropping. 
[0072] interaction device 290 may provide instructions to the is- 
suer systems 230 for requesting receipt of issuer-owned 
data, such as for example, account data, user member 
identification data, member demographic data, or the like, 
which the issuer wishes to store on the financial transac- 
tion instrument 240. The interaction device 290 may 
communicate with the issuer systems 230 using an issuer 
recognizable communications protocol, language, meth- 
ods of communication and the like, for providing and re- 
ceiving data. In one exemplary embodiment, issuer- 
owned data is received by the interaction device 290 from 
issuer systems 230, and stored onto the financial transac- 



tion instrument 240. The data may be stored or manipu- 
lated in accordance with the issuer provided instructions, 
protocol, storage format, header or trailers received by 
the interaction device from issuer systems 230. The is- 
suer-owned data may be stored on the financial transac- 
tion device 240 in any format recognizable by a merchant 
system 280, and further recognizable by issuer system 
230. In one exemplary embodiment, the issuer owned 
data is stored using a issuer system 230 format which 
may be later formatted in merchant system 280 recogniz- 
able protocol when provided to the merchant system 280. 
In one embodiment, the issuer-owned information is 
stored on the financial transaction instrument 240 in the 
identical format with which it was provided by the issuer 
system 230. In that regard, interaction device 290 may be 
any device configured to receive issuer-owned data from 
an issuer system 230, and write the data to a database, 
such as, for example, a database on instrument 240 or 
database 282. Further, as described more fully below, the 
issuer-owned information may also be provided by the is- 
suer 230 to a remote database 282 where the information 
is stored such that it mirrors the corresponding informa- 
tion stored on the transaction instrument 240. 



[0073] As noted, in accordance with the invention, a transaction 
device is provided which permits the storage and present- 
ment of at least one of a plurality of data sets for com- 
pleting a transaction. In one exemplary embodiment, the 
interaction device 290 may be configured to add the is- 
suer-owned data to the transaction device when the 
transaction device 240 is initially configured, prior to pro- 
viding the transaction device 240 to the user 201. The in- 
teraction device 290 may additionally be configured to 
add additional distinct data sets owned by other distinct 
issuers on the transaction device 240 when the transac- 
tion device 240 is next presented, for example, to the 
stand-alone interaction device 290. In this regard, the in- 
teraction device 290 may receive from multiple distinct is- 
suer systems 230, via the network 260, the issuer pro- 
vided protocol/instructions and additionally may load the 
additional distinct data sets on the transaction device 240 
in real-time, substantially real-time, or in a batch pro- 
cessing mode. The additions may be provided to the in- 
teraction device 290 for storage and later use when the 
transaction device 240 is next presented. Alternatively, 
the interaction device 290 may be configured to retrieve 
the instructions from the issuer system 230 when the 



transaction device 240 is next presented to interaction 
device 290, on a random basis, during a predetermined 
time period (e.g., every presentment for the next three 
days), at predetermined intervals (e.g., every third pre- 
sentment) and/or the like. Similarly, any of the devices 
discussed herein may communicate or exchange data at 
similar time periods or intervals. Further, where other de- 
vices, such as, for example, a kiosk 270, merchant point 
of interaction device, or the like, are likewise configured 
to add the issuer data on transaction device 240, the in- 
vention contemplates that the real-time or substantially 
real-time adding of the above distinct data sets in similar 
manner as is described with the interaction device 290. 
[0074] Alternatively, the device to which the transaction device 
240 may be presented may not be equipped for adding 
the data to the transaction device 240. For example, mer- 
chant system 220 may be any conventional merchant sys- 
tem which communicates to an issuer system 230, and 
which permits a user 201 to complete a financial transac- 
tion, but which is not configured to add the issuer data 
contained on the transaction device 240. In general, con- 
ventional merchant systems are not configured to write or 
overwrite data included on the payment devices presented 



to the merchant system for processing. That is, the mer- 
chant system 220 may include little or no additional soft- 
ware to participate in an online transaction supported by 
network 260. Loading of the data sets on transaction de- 
vice 240 may be performed independent of the operation 
of the merchant system 220 (e.g., via issuer system 230 or 
interaction device 290). As such, the present invention 
may not include retrofitting of the merchant system 220, 
to accommodate system 200 operation. Thus, where the 
merchant system 220 is not configured to add the data on 
the transaction device 240, such additions of the data set 
may be made using the interaction device 290 or directly 
using an issuer system 230 as described above. 
[0075] The merchant system 220, kiosk 270, interaction device 
290, may include additional components or methods for 
permitting the transaction device user 201 to self-add the 
data onto the transaction device 240. In this case, the 
systems 220, 270, and 290 may include an additional user 
interface for use by the user 201 to identify the adding 
action to be taken. Where the systems 220, 270, and 290 
are configured to communicate with the transaction de- 
vice 240 and to add the data sets thereon, the additions 
may be completed or substantially completed in real-time 



or substantially real-time. For example, the user 201 may 
present the transaction device 240 to one of the systems 
220, 270, or 290, provide instructions (e.g., "ADD DATA 
SET")for adding the data on transaction device 240 to the 
system 220, 270, or 290, and system 220, 270, or 290 
may add the data onto the transaction device 240 in real- 
time or substantially real-time, for example, prior to per- 
mitting the transaction device 240 to be used by the user 
201 to complete a transaction. Alternatively, the instruc- 
tions for adding data sets may be provided by the user 
201 to the merchant system 220 or kiosk 270, and the 
merchant system 220 or kiosk 270 may further provide 
the instructions to the network 260 for use in later adding 
the data. For example, the instructions may be provided 
by system 220 or 270 to the issuer system 230 managed 
by the issuer owning the data to be added. The issuer 
system 230 may provide the data sets to be added to, for 
example, interaction device 290, for updating the trans- 
action device 240 when next presented. In one exemplary 
embodiment, the instructions may be stored at the issuer 
system 230, until such time as the transaction device 240 
is next presented to a device configured to add the data 
on the transaction device 240. Once presented, the data 



set may be provided to the device (e.g., computer 250, in- 
teraction device 290, etc.) for storing the data set on the 
transaction device 240. 
[0076] | n another exemplary embodiment, the user 201 may 
self-manage the data sets by, for example, adding data 
sets using a conventional computer system 250, which 
may be in communication with the network 260. Com- 
puter system 250 may or may not be configured to inter- 
act with RF transaction device 240. Where the computer 
system 250 is not configured to interact with the transac- 
tion device 240, the user 201 may provide instructions for 
adding data sets to the issuer system 230 for later use in 
adding data to the corresponding transaction device 240 
data, for example, when the transaction device 240 is 
next presented in similar manner as described above. 
Where the computer 250 is configured to interact with the 
RF transaction device 240 to modify the data stored 
thereon, the user 201 may provide instructions to the 
computer 250 for adding the data on the RF transaction 
device in real-time or substantially real-time. Conse- 
quently, the computer 250 may receive adding instruc- 
tions from the user 201 and perform the additions ac- 
cordingly, and may add the data to the transaction device 



240 in real-time or substantially real-time. The computer 
250 may additionally be configured to receive authoriza- 
tion of the adding instructions from issuer system 230 
prior to making the user 201 requested additions. The is- 
suer system 230 may receive the user 201 instructions 
and verify whether the identified additions of data sets are 
available to the user 201 or if the identified data sets are 
valid. If the identified additions and data sets are autho- 
rized, the issuer system 230 may add the data to a trans- 
action device database including a distinct data storage 
area associated with the issuer system 230. Any manage- 
ment of the data sets discussed herein may include au- 
thorizations, restrictions or levels of access as is known in 
the art. 

[0077] | n one exemplary method of self-management, a user 201 
logs onto a website via user computer 250, or onto a 
stand-alone device, such as, for example, interaction de- 
vice 290 or kiosk 270, and selects an option for adding 
data sets on a RF transaction device 240. The additions or 
requested additions may be transmitted to the transaction 
device 240 via a reader/writer device 280 configured to 
communicate the data to transaction device 240. In this 
context, the reader/writer device 280 may be any conven- 



tional transaction device reader or writer. 
[0078] a transaction device database in accordance with the 

present invention may be any type of database, such as 
relational, hierarchical, object-oriented, and/or the like. 
Common database products that may be used to imple- 
ment the databases include DB2 by IBM (White Plains, New 
York), any of the database products available from Oracle 
Corporation (Redwood Shores, California), Microsoft Ac- 
cess or MSSQL by Microsoft Corporation (Redmond, Wash- 
ington), or any other database product. A database may 
be organized in any suitable manner, including as data ta- 
bles or lookup tables. Association of certain data may be 
accomplished through any data association technique 
known and/or practiced in the art. For example, the asso- 
ciation may be accomplished either manually or automati- 
cally. Automatic association techniques may include, for 
example, a database search, a database merge, GREP, 
AGREP, SQL, and/or the like. The association step may be 
accomplished by a database merge function, for example, 
using a "key field" in each of the manufacturer and retailer 
data tables. A "key field" partitions the database according 
to the high-level class of objects defined by the key field. 
For example, a certain class may be designated as a key 



field in both the first data table and the second data table, 
and the two data tables may then be merged on the basis 
of the class data in the key field. In this embodiment, the 
data corresponding to the key field in each of the merged 
data tables is preferably the same. However, data tables 
having similar, though not identical, data in the key fields 
may also be merged by using AGREP, for example. 
[0079] As noted, in some exemplary embodiments of invention, 
authorization may be obtained from issuer systems 230 
prior to adding, deleting or manipulating the data on 
transaction device 240. Authorization may be obtained by 
requesting the authorization during the process of adding 
the data sets to the transaction device 240. Authorization 
may be given where the user 201 provides appropriate 
security information, which is verified by the issuer sys- 
tem 230. The security information may be, for example, a 
security code granting access to the issuer-owned data on 
the transaction device 240. For example, a point-of-sale 
machine may be configured to allow the input of a code, 
or an answer to a prompt, which is provided to and veri- 
fied by issuer system 230. Once verified the addition of 
data requested may be made to the data contained on the 
RF transaction device. 



[0080] ^ should be noted that the authorization code may be 
used to permit the user 201 to select which issuer pro- 
vided data to utilize for completion of a transaction. For 
example, a point of interaction device (POI) device may be 
programmed to search the RF transaction device for a 
data set containing a particular club membership data set, 
or to locate all available data sets for providing to a user 
201 display available data sets to the user 201, thereby 
permitting the user 201 to select which data set to use to 
complete a transaction. If no data set is found, the POI 
device may alert the user 201 or prompt the merchant to 
alert the user 201 of the possibility of adding issuer- 
owned data to the RF transaction device. A positive re- 
sponse to this alert may cause the POI device to add an is- 
suer data set to the transaction device. Additional security 
on the transaction device 240 may prevent access to cer- 
tain data by any parties discussed herein. 

[0081] it is noted that the user 201 may already be a member of 
a membership program managed by an issuer system 230 
in which case the associated user 201 membership data 
may be assigned to user 201 for inclusion on transaction 
device 240. As such, the user 201 may be permitted to 
add the membership data set to the transaction device 



240. Alternatively, the user 201 may become a member by 
selecting to add the membership information to the RF 
transaction device, using the interactive device 290. In 
some embodiments, changes made to the data sets stored 
on the transaction device 240 may be updated to the RF 
transaction device 240 in real-time or substantially real- 
time, where the interactive device 290 is in communica- 
tion with the transaction device 240. The changes may 
also be completed the next time the user 201 presents 
the RF transaction device 240 to a stand-alone interaction 
device 290 or to a kiosk 270, merchant system 220, or 
the like. 

[0082] | n another exemplary embodiment of the present inven- 
tion, merchant system 220, kiosk 270, and/or user com- 
puter 250 may be configured to interact with RF transac- 
tion device 240 via a read/write device 280. Read/write 
device 280 may be any device configured to communicate 
with RF transaction device 240. In one embodiment, read/ 
write device 280 is configured to read and write to RF 
transaction device 240. For example, read/write device 
280 may be a point of interaction magnetic card reader/ 
writer. In another example, where the transaction device 
includes a RF transmitter/receiver for communicating with 



system 200, read/write device 280 may include a mating 
transponder configured to receive and transmit issuer- 
owned data. Read/write device 280 may be configured to 
select data sets for use by a merchant using any suitable 
selection technique including but not limited to propri- 
etary commands or command sequences or use of ISO/IEC 
7816-4 application selection sequences (e.g., GET com- 
mand). 

[0083] Managing of he data sets (step 116) as used herein may 
include adding the data sets to the transaction device 240 
database. More particularly, FIG. 3 illustrates a general 
overview of an exemplary data set management method 
300 comprising the steps of: a data set (step 310), initial- 
izing a data set (step 320), and verifying availability of 
data set (step 330). In this manner, a data set may be 
added to a RF transaction device, initialized and verified 
for usage in the completion of a transaction. Furthermore, 
the ability to update, modify, replace and/or delete a data 
set may be subject to security requirements. 

[0084] | n one embodiment exemplifying self-management of the 
transaction device database, the various processes may 
include a user 201 facilitating the input of information 
into a data management system 200 to cause the data set 



to be loaded. The information may be inputted via key- 
pad, magnetic stripe, smart card, electronic pointer, 
touchpad and/or the like, into a user computer 250, POS 
terminal, kiosk 270, ATM terminal and/or directly into the 
merchant system 220 via a similar terminal or computer 
associated with merchant server 222. The information 
may be transmitted via any network 260 discussed herein 
to merchant system 220 or issuer systems 230. In another 
embodiment, the merchant may enter the information into 
an issuer system 230 on behalf of the user 201. This may 
occur, for example, when the user 201 and/or issuer sys- 
tem 230 authorizes the management of data sets on RF 
transaction device 240 over a telephone and the service 
representative inputs the information. In this embodi- 
ment, the transaction device 240 may be updated at the 
next presentment opportunity. 
[0085] Any psuitable rocedures may be utilized to determine 

whether a data set is currently ready for use and available 
(step 330). In one example, when a financial transaction 
device 240 is presented, the availability of the data set is 
verified by checking whether the data set has been cor- 
rupted or blocked (step 332), or deleted (step 333). For 
example, the data set may be checked to determine if the 



data set has been accessed or altered without permission 
("corrupted") or if the data set exists or has been removed 
from the transaction device 240("deleted"). The check may 
be performed using any suitable protocol or comparing 
data. If the answer to these questions is no, then the data 
set is available and ready for use (step 334). If the data is 
corrupted or blocked, subroutines may be used to attempt 
to retry reading the data (step 336). If the data set is 
marked deleted or removable, subroutines will prevent 
access to the data set (step 335) and remove the data set 
(step 340). For example, a suitable subroutine may place a 
DELETE "marker" on the data set, which prevents the data 
from being transmitted during completion of a transac- 
tion. The data set may then be marked for deletion and 
deleted from the transaction device 240 at the next pre- 
sentment of the device. In similar manner, where the data 
set is corrupted, a CORRUPTED marker may be appended 
to the data set and the data set is prevented from being 
transmitted during completion of a transaction. The 
marker may be a header or trailer as discussed herein. 
[0086] Various methods may be used to add a data set to a fi- 
nancial transaction device 240 or to replace a data set on 
a financial transaction device 240. FFIG. 4 illustrates an 



xemplary method of adding a data set to a financial trans- 
action device 240, including the general steps of present- 
ing the financial transaction instrument (step 410), verify- 
ing the addition of the data set to the financial transaction 
instrument (step 420), placing the data set in a temporary 
holding area (step 430), and adding the data set (step 
440). 

[0087] M 0re particularly, the user 201 presents the financial 

transaction device 240( tep 410) to a device 280 config- 
ured to communicate with device 240. The user 201 may 
present financial transaction device 240 at a point of pur- 
chase or to an interaction device 240o r kiosk 270. For 
example, the user 201 may wave the RF transaction device 
240i n front of a POI machine in a retail store, which is 
configured to receive data from the device 240. Alterna- 
tively, the user 201 may present the financial transaction 
device 240 at a self-service location such as a kiosk 270 
in a mall. Moreover, the user 201 may present the finan- 
cial transaction device 240 to a peripheral device associ- 
ated with a personal computer, or the like. 

[0088] The user 201 is then given the opportunity to add a data 
set to the transaction device 240. For example, device 280 
may detect the absence of a particular data set on the 



transaction instrument by searching the transaction device 
240 databases and comparing the existing data sets to 
the data set to be added. If the data set to be added is not 
found on the database, the user 201 may be prompted to 
confirm the addition of this data set to the instrument 
(step 420). The user may be prompted via an interactive 
user interface displaying the option to add the data set. In 
one example, when a user 201 presents a financial trans- 
action device 240 to a merchant, the card reader detects 
the absence of a loyalty data set and provides a message 
on a display to the user 201 or the store clerk indicating 
that the loyalty data set can be added if desired. The user 
201 may answer in the negative and complete the pur- 
chase using typical transaction methods (step 425). Alter- 
natively, if user 201 provides an affirmative response, the 
algorithm may prepare a data set for communication with 
the financial transaction device 240 (step 430). The pro- 
cess may determine whether the data set (or information 
that could be used to create the data set) exists in some 
form or on some device other than on the financial trans- 
action device 240 (step 432). Determining whether a data 
set exists may involve querying an issuer system 230, 
database 282, or the like. For example, the issuer system 



230 may compare the data set to other data sets the is- 
suer system 230 has assigned to a particular user 201. If 
the data set is not assigned to a particular user, then is- 
suer system may determine that the data set is available 
for adding to the transaction device 240. Determining 
whether a data set exists may also take place when a store 
clerk verbally asks (or a screen prompts) the user 201 to 
present another card containing the information. For ex- 
ample, the data set may exist on a movie rental card and 
stored in magnetic stripe form, bar code, and/or the like. 
[0089] if the data set exists in an accessible form, the data set 
may be captured(step 436). In this example, the user 201 
may present the movie rental card and the data read from 
the movie rental card may then be stored in a data set as- 
sociated with the financial transaction device 240. For ex- 
ample, the user 201 may desire to add a shopping loyalty 
card to the user"' 201 financial transaction device 240. 
The user 201 may swipe, scan or otherwise present the 
loyalty card such that the data set from the loyalty card is 
captured. The system may be further configured such that 
the merchant, kiosk 270, or computer system may access 
an issuer system 230 to obtain information for creating 
the data set. Thus, if a user 201 does not have the movie 



rental card on tthe user's 201person, the system 230 may 
prompt the clerk to request identifying/security informa- 
tion and to access tthe user's 201 ccount and therefore 
facilitate adding a movie rental data set associated wwith 
the user's 201 ransaction device 240. Any other suitable 
methods of capturing data sets may also be used. 

[0090] if the data set does not exist, a new data set may be cre- 
ated (step 434) for inclusion on the transaction device 
240. Creation of the data set may, for example, involve 
filling out an application, providing name and address, 
creating an account, and/or the like. In either event, the 
pre-existing or newly created data set is temporarily held 
in a storage area (e.g., database 282, local memory or the 
like) for transfer to the transaction device 240 (step 438). 
Additional data sets may be prepared for transmittal to 
transaction device 240 (step 439). I 

[0091] | n this exemplary embodiment, the transaction device 240 
is presented again to read/write device 280 (step 442). 
Read/write device 280 is configured to attempt to transfer 
the data set(s) to the transaction device 240 (step 444). 
For example, existing read/write device 280 may be con- 
figured with software and/or hardware upgrades to trans- 
mit data to the transaction device 240. In one exemplary 



embodiment, if the data sets were not transferred cor- 
rectly, the process may try the transfer again. In another 
exemplary embodiment, data sets are added one at a time 
or altogether. Thus, a user 201 may pass a card through a 
card reader/writer one or more times during the addition 
process. The transaction may be completed (step 425) us- 
ing the new data set or another selected method of pay- 
ment. The same steps may be used in a self-service em- 
bodiment, however, in one embodiment, no financial 
transaction takes place along with the addition of data 
sets. It should also be noted that under appropriate cir- 
cumstances, a user 201 could add data sets at a point of 
purchase without actually completing a purchase. 
[0092] | n various exemplary embodiments, the user 201 and/or 
the owner of the data set may manage the data set (i.e., 
steps 432-439) in advance of presenting the transaction 
device 240. For example, a user 201 on user computer 
250 may choose to add or delete data sets via a website 
configured for management of data sets. In another ex- 
ample, an issuer system 230 may add functionality to an 
account and may desire to update the data set associated 
with that account. In either example, data sets that have 
been prepared in advance may be ready for transmission 



upon presentment of the transaction device 240. The 
transmission of the data sets may be transparent to the 
user 201. For example, the user 201 may present the 
transaction device 240 (step 442) to complete a purchase 
and the waiting data sets may automatically be added to 
the user's 201 card (step 440). 
[0093] As noted, the data associated with the transaction device 
240 may be modified by the user 201 and/or by the issuer 
system 230. FIG's. 5 and 6 respectively, depict exemplary 
methods for user 201 and issuer system 230 data man- 
agement. For example, with respect to user 201 self- 
management, the issuer system 230 may provide the user 
201 with a transaction device 240 (step 502). The trans- 
action device 240 may be provided with pre-stored is- 
suer-owned data, or the device may be configured to per- 
mit the user 201 to add the data at a later date. The user 
201 may then present the transaction device 240 to read/ 
write device 280 for initiating the self-management pro- 
cess (step 504). The read/write device 280 may then read 
the data on the transaction device 240, and provide the 
data to an interaction device 290 for displaying to the 
user 201 (step 506). Alternatively, the interaction device 
290 may provide the user 201 a list of available data to be 



added to the transaction device 240. 

[0094] The user 201 may then be permitted to identify which 

data the user 201 wishes to add (step 508). Identification 
of the data may include providing the data with a trailer or 
header indicating the adding action to be taken. The 
header and an indicator of the data to be added may then 
be provided to the issuer system 230 (step 510) for verifi- 
cation as to whether such desired additions are available 
to the user 201 (step 512). If the desired additions are not 
available, the additions will not be made and the user 201 
is notified accordingly (step 514). The user 201 may then 
be permitted to identify whether other data is to be added 
(step 516). If so (step 508), the interaction device 290 
may provide a request for adding to the issuer system 230 
(step 510) and the verification process is repeated. 

[0095] Alternatively, where the issuer system 230 verifies that the 
additions of distinct data sets may be made (step 512), 
the interaction device 290 may provide instructions to the 
interaction device 290 to the appropriate data on the 
transaction device 240 (step 518). The user 201 may then 
be permitted to select other data sets to add (step 516), in 
similar manner as was described above. Where the addi- 
tion of data sets is complete, the user 201 may then 



present the transaction device 240 to a merchant for use 
in completing a transaction. 
[0096] FIG. 6 depicts an exemplary method wherein the issuer 
system 230 manages the data contained on the transac- 
tion device 240. For example, the issuer may identify on 
the issuer system 230 which data sets are to be added to 
the transaction device database (step 602). The device 
240 may be provided with pre-stored issuer-owned data, 
or the instrument 240 may be configured to permit the 
user 201 to add the data at a later date. The user 201 may 
the present the transaction device 240 to read/write de- 
vice 280 for initiating the self-management process (step 
604). The read/write device 280 may then read the data 
on the transaction device 240, and provide the data to an 
interaction device 290 for displaying to the user 201 (step 
606). Alternatively, the interaction device 290 may provide 
the user 201 a list of available data to be added to the in- 
strument 240. 

[0097] | n addition, the issuer system 230 may query as to 

whether the issuer system 230 is in possession of the 
transaction device 240 for making the additions to the 
data set on the transaction device 240 in real-time or 
substantially real-time (step 608). If so, the additions are 



made accordingly (step 610) and the transaction device 
240 may then be authorized for use in completing a 
transaction using the distinct data set added (step 612). 
[0098] where the issuer system 230 is not in possession of the 
transaction device 240 at the time the issuer determines 
that the addition of the distinct data sets on the transac- 
tion device 240 are to be made (step 608), the distinct 
data sets to be added may be made on the issuer system 
230 (step 604), and may be placed in queue on the issuer 
system 230, for uploading to the transaction device 240 
when it is next presented to the issuer system 230 or to 
an appropriate read/write device 280 (step 614). When the 
transaction device 240 is presented thusly (step 616), the 
issuer system 230 may be notified that the transaction 
device 240 is available for adding the identified distinct 
data sets, and the issuer system 230 may then provide the 
instructions for addition (e.g., modified data including 
headers) to the appropriate read/write device 280 for 
adding the data sets to the transaction device 240 (step 
618). The transaction device 240 may then be provided to 
the user 201 for use in completing a transaction (step 
612). 

[0099] As noted, the transaction device 240 may include multiple 



data sets which correspond to distinct issuer systems 230, 
and which may be used to complete a transaction. The 
user 201 may be permitted to choose which data set to 
use for transaction completion. FIG. 7 illustrates an exem- 
plary method by which the user 201 may choose which of 
the data sets to use to complete a transaction. For exam- 
ple, the user 201 may present the transaction device 240 
to a merchant system for use in completing a transaction 
(step 702). The merchant system 220 may then read the 
data stored on the transaction device 240 and report to 
the user 201 all distinct data sets which may be used to 
complete a transaction (704). The user 201 may then se- 
lect the appropriate data set (step 706) and the transac- 
tion is completed accordingly (step 708). 
[° 10 °] It should be noted that completion of a transaction may 
be performed under any business as usual standard em- 
ployed by the merchant and/or issuer system 230. For 
example, the merchant server 222 may be configured to 
communicate transaction data to the appropriate issuer 
system 230, in real-time or substantially real-time, or by 
using batch processing at the end of each day. Any suit- 
able means for delivering the transaction data to the is- 
suer systems 230 may be used. In one exemplary embod- 



iment of the present invention, the transaction data may 
be delivered to the issuer system 230 via a network 260. 
The issuer system 230 may receive the transaction infor- 
mation and process the transaction under issuer defined 
protocol independent of any other protocol used by other 
issuers to process a transaction. The issuer system 230 
may receive the transaction data then provide the mer- 
chant with the appropriate satisfaction for the transaction. 

[° 101 ] It should be appreciated that the particular implementa- 
tions shown and described herein are illustrative of the 
invention and its best mode and are not intended to oth- 
erwise limit the scope of the present invention in anyway. 
Indeed, for the sake of brevity, conventional data net- 
working, application development and other functional 
aspects of the systems (and components of the individual 
operating components of the systems) may not be de- 
scribed in detail herein. It should be noted that many al- 
ternative or additional functional relationships or physical 
connections may be present in a practical data set man- 
agement system. 

[0102] As may be appreciated by one of ordinary skill in the art, 
the present invention may be embodied as a method, a 
data processing system, a device for data processing, 



and/or a computer program product. Accordingly, the 
present invention may take the form of an entirely soft- 
ware embodiment, an entirely hardware embodiment, or 
an embodiment combining aspects of both software and 
hardware. Furthermore, the present invention may take 
the form of a computer program product on a computer- 
readable storage medium having computer-readable pro- 
gram code means embodied in the storage medium. Any 
suitable computer-readable storage medium may be uti- 
lized, including hard disks, CD-ROM, optical storage de- 
vices, magnetic storage devices, and/or the like. 
[0103] These computer program instructions may also be stored 
in a computer-readable memory that can direct a com- 
puter or other programmable data processing apparatus 
to function in a particular manner, such that the instruc- 
tions stored in the computer-readable memory produce 
an article of manufacture including instruction means 
which implement the function specified in the flowchart 
block or blocks. The computer program instructions may 
also be loaded onto a computer or other programmable 
data processing apparatus to cause a series of operational 
steps to be performed on the computer or other pro- 
grammable apparatus to produce a computer-imple- 



merited process such that the instructions which execute 
on the computer or other programmable apparatus in- 
clude steps for implementing the functions specified in 
the flowchart block or blocks. 
[0104] | n the foregoing specification, the invention has been de- 
scribed with reference to specific embodiments. However, 
it may be appreciated that various modifications and 
changes can be made without departing from the scope of 
the present invention. For example, the issuer may reserve 
all management of data stored on the transaction device, 
thereby prohibiting the user from modifying the issuer- 
owned data thereon. Further, each issuer system may 
have its own data management protocol, which necessar- 
ily does not interfere with or depend upon the data man- 
agement protocol of other issuer systems. As such, the 
specification and figures are to be regarded in an illustra- 
tive manner applicable irrespective of the data processing 
protocol used by a data set owner, rather than a restrictive 
one, and all such modifications are intended to be in- 
cluded within the scope of the present invention. Accord- 
ingly, the scope of the invention should be determined by 
the appended claims and their legal equivalents, rather 
than by the examples given above. For example, the steps 



recited in any of the method or process claims may be ex- 
ecuted in any order and are not limited to the order pre- 
sented. 

[0105] Benefits, other advantages, and solutions to problems 
have been described above with regard to specific em- 
bodiments. However, the benefits, advantages, solutions 
to problems, and any element(s) that may cause any ben- 
efit, advantage, or solution to occur or become more pro- 
nounced are not to be construed as critical, required, or 
essential features or elements of any or all the claims. As 
used herein, the terms "comprises," "comprising," or any 
other variation thereof, are intended to cover a non- 
exclusive inclusion, such that a process, method, article, 
or apparatus that comprises a list of elements does not 
include only those elements but may include other ele- 
ments not expressly listed or inherent to such process, 
method, article, or apparatus. Further, no element de- 
scribed herein is required for the practice of the invention 
unless expressly described as "essential" or " critical." 



